OpenStreetMap
iD editor: It is time for us to end this abusive relationship
Posted by woodpeck on 9 November 2019 in English.It all started out nice enough, the Knight Foundation paying for a team of professional developers at Mapbox to develop a new, user-friendly website editor to replace the ageing, Flash-based Potlatch. This brought us the iD editor which for roughly six years now has been the default editor we present to new users, and the user friendliness of this endeavour is certainly unparalleled in OSM.
To new users, this editor represents our project and our community. If this editor tells them that they should do something this way or that, they will assume that “OpenStreetMap wants me to do this”. The iD editor is the only editor endorsed by the OSM Foundation in this way, and with great power comes great responsibility.
A responsibility that the iD team is increasingly unable to shoulder.
There wasn’t much to complain during the early years except perhaps the lack of support for one thing or another, cases where everyone including the developers agreed that improvements need to be made. But now that the basic functionality is there, iD developers are starting to believe they have a mandate for more. Rather than just giving users a tool to contribute to OSM, they are directing users to contribute in certain, very specific ways - preferring one tag over another, using one channel of communication with the community instead of another, “upgrading” the work of other users according to rules set out by the editor developers alone, striking deals with commercial validation platforms, loading auxiliary data from Facebook without the user’s consent or any previous discussion, and so on.
Pushback from the community against these unilateral decisions is met with abject arrogance. Issues opened on the project issue tracker are closed as “too heated”. Benign suggestions to discuss the problem are batted away; the attitude of the iD team seems to be either that they know better what is good for us, or that we’re free to go if we don’t like what they do. Even community members who are otherwise full of praise for corporate involvement seem to despair at the presumptuous attitude and lack of community consultation of the iD project.
We are not that desperate for love that we need to continue this abusive relationship. Let us stop using that “official” version of iD today, and switch to the community version of iD maintained by Frédéric Rodrigo (see also his tweet). With his experience from a decade of working with our community and respecting community consensus in Osmose and other projects, Frédéric knows how to run a project like that without everyone burning out because of “too heated” discussions.
Will this cut us off from new developments made by the main iD developers? Absolutely. But I think an editor that respects our community consensus is more important than having a nice auto-complete that ensures the correct spelling of an American fast-food franchise outlet.
PS: I’ve not been naming names on purpose. If you have contributed to iD development and managed to refrain from showering anyone who asked for a change with condescension, good for you; sadly it doesn’t change the fact that decision-making in iD has become unstuck from what the community expects of software they imbue with the privilege of being “the official editior”. And the community is not the five people going to lunch with the developer.
Discussion
Comment from mmd on 9 November 2019 at 13:13
I hope you’re aware that http://id.openstreetmap.fr/ was built by patching a still unreleased iD v3 version, and modifying some of its JSON configuration settings. It reflects some intermediate development state of a future iD version, where hundreds of changes and fixes have been contributed in the meantime. Then, https://github.com/frodrigo/iD doesn’t provide any way to file any issues on its own. Needless to say that this overall approach won’t fly.
Comment from marc__marc on 9 November 2019 at 13:29
no, it’s done on v2.15
he’s using https://wiki.openstreetmap.org/wiki/ID/Controversial_Decisions
Comment from mmd on 9 November 2019 at 13:35
No, it definitely not v2.15. Take a look at https://preview.ideditor.com/release which hosts v2.16 and see how they differ. Did you notice that http://id.openstreetmap.fr/ is in fact based on the master branch, and looks very much like https://preview.ideditor.com/master. The master branch is where the future development for v3 happens. There’s a dedicated branch for v2.15, though.
Comment from frodrigo on 9 November 2019 at 14:28
My idea is not to fork iD and even less to maintain a fork. But rather show the list of controversial decisions could be addresses with patchs. The number of, and the patchs are not large. Writing the patchs and maintained can be done. This approach could probably be applied to brand logos and so on. This changes are mostly configuration, or configuration-like part of iD, not real software code.
Because I obliviously care about the OSM Data. I also agree with the content of this diary. We should no more deploy the default iD on osm.org. I aim to show a set of patchs can be done and maintained.
Comment from frodrigo on 9 November 2019 at 16:47
I switched http://id.openstreetmap.fr/ to v2.16.0.
Comment from frodrigo on 9 November 2019 at 19:18
Add a new patch to use only logo from commons.wikimedia.org, not from facebook not twitter https://github.com/frodrigo/iD/commits/compliance_v2.16.0
Comment from SimonPoole on 9 November 2019 at 20:05
Just as a note: the (legal) privacy concerns are no different with wikimedia commons than with any other 3rd party, in particular any other US based 3rd party, that we asking our contributors to involuntarily submit their data to.
A proper solution needs to be opt-in and there needs a way to
Simon
Comment from phidauex on 10 November 2019 at 18:16
I don’t have any stake in the matter, except as a user of the tools, but I do want to speak in defense of the iD team. I observe their day-to-day interactions on the OSM-US Slack, and it has been my impression that they are extremely responsive to bug fixes, clearly doing a lot of work on personal time, and helpful to users who have questions or concerns about presets, documentation, and other aspects of the project. As an outside user, it strikes me as a very well run OS project.
Where things have gotten tense recently, it seems to be around issues and other discussion that is less about the code and the tool, and more about broader arguments around data privacy (which I care about as well), finer points of licensing or the role of different members or teams in the community. It can come off as quite personal, and puts a bit of an unfair onus on a few developers to defend the strategy of a whole organization. Being the maintainer of a core application like this puts a giant target on their backs, and I would hope you can see how that is a stressful position to be in.
I’d like to think that some well thought out patches would be accepted by the id folks, if they are focused on the tool itself, rather than any larger grievances with OSM, OSMF, OSMUS, Mapbox, etc. Assume good faith, and remember that in all cases here we are dealing with individual people, not faceless organizations.
Comment from ThatOneDoge on 10 November 2019 at 18:22
I think the main concern here is iD’s pushiness in suggested tagging as opposed to other editors’ very open-ended approach. I think that in most cases, it’s not a problem that iD has this. When I was brand new to OSM(and I’m not that experienced even still), iD made it so that I could add to the map without knowing what a tag even was. That’s a good thing, because it meant I could use the editor without hardly any kind of learning curve, and gradually learn more about tagging protocol as I became more interested in OSM. Now, before I start mapping something new, I often use taginfo, the wiki, and sometimes I check with some other mappers. I haven’t used the iD version you mentioned, but if it is less aggressive in suggesting tags, I’d be VERY hesitant to agree with you. iD is an in for newbies that can be used in more advanced ways later, and I think it does what it does excellently.
Comment from maxerickson on 10 November 2019 at 18:56
Is If you have contributed to iD development and managed to refrain from showering anyone who asked for a change with condescension, good for you; sadly it doesn’t change the fact that decision-making in iD has become unstuck from what the community expects of software they imbue with the privilege of being “the official editior”. And the community is not the five people going to lunch with the developer. meant to be ironic?
(what I mean is, I think, despite disagreements, the various people involved are well aware of the nature of the OSM community and it is a bit condescending to dismiss the existence of that understanding and then speak as if you are an affirmative representative of the entire mess that is the OSM “community”)
The worst thing about all this crap is that it is just reaction to change. It’s good for OSM to consolidate tags that mean the same thing, even if in the past it was better for OSM to do something else. We should move on from poorly thought out tag schemes. We should pick winners when multiple tags mean the same thing.
I also think you could have been much more careful in characterizing the situation. iD accepts lots of tagging related pull requests, it isn’t closed off or the work of a few people. And then the situation with third party content is going to be resolved by notifying users and asking for consent. The horror.
Comment from RobJN on 10 November 2019 at 20:32
Hi Frederik,
Given that you linked to one of my emails, I felt it best to share some thoughts especially as I do not think you have identified the root cause of the issue. But first to address your request.
Yes we can “stop using that “official” version of iD” however the issues you discuss are not limited to iD. I have experienced the same issues within numerous OpenStreetMap projects and there seems to be no link between whether they are run by volunteers or by corporate employees. In fact in one such volunteer example I stopped posting issues several years ago as it became clear that they also had very little interest in the UK specifics I was describing. There is another project (again community run) that I would think twice about posting an issue to given my observations of the way they treat others. So, yes we can “stop using that “official” version of iD” but if we do can we also stop using the “official” version of other OSM projects featured on, or linked to from openstreetmap.org?
So what is the root cause? It could possibly be the core value of OpenSreetMap itself - “do-ocracy”. The problem with do-ocracy is that not everyone comes to OpenStreetMap with the same skill set. Most can do basic map edits but after that the number drops dramatically. Using iD as the example here, the number of members within the OpenStreetMap community who have the right skills to contribute to iD is very small. The same applies to the community run projects I have experienced issues with - the common feature is that most of the community are locked out of these projects because they do not possess the right skill set.
The issue with a do-ocracy is that individuals are faced with two choice: (1) commit serious amounts of time to learn every the skills required to contribute to single element of OpenStreetMap, or (2) rely on the goodwill of others and hope that those others also share your point of view.
In reverse order: the issue with (2) is that you will not always succeed. Individuals have their own approach (whether paid or by a company or contributing in their spare time). Sometimes they share the same my point of view, sometimes they don’t. Some are ok at reading the mood of the community, others less good. Who can blame them - the community is complex and rarely appears to agree (it takes just 1 loud person to express an opposite opinion even if the other 99 mostly silent people agree).
The solution I hear most often is choice (1) - i.e. teach yourself and join the do-ocracy. However there is a major problem here. We want as many mappers as possible to contribute to OSM. As such we need to be attracting people from all walks of life, including those who may just want to dip in and make a small edit every now and then. They might still be passionate about OpenStreetMap’s aim (free geospatial data of the world) but they are held out of many aspects of the project unless they learn all the skills we demand.
So what is the solution? Personally I’m not sure but it somehow has to lie in channelling the energy of those who do have the right skills. This is something we are not very good at. We are quick to disagree when that energy is used to do something we disagree with, but as a group we are very bad at channelling that energy to our benefit. Perhaps that is because we have never figured out what the agreed “benefit” is. As such the small group within the do-ocracy are left to their own devices and are left to figure out for themselves how to help the wider community. As noted above, some people are better at this than others, but one thing is common - when they get it wrong they face abuse.
Hopefully in time we will find better ways to strengthen the OpenStreetMap community and get it to the point where it can express clearly it’s wishes as one community rather than the current he/she who shouts the loudest. If we can do that, then we (and the OSMF) can focus on pulling in as much help and possible (community volunteer, corporate employee time or corporate money) and channelling it to the things that the community agrees it wants.
For now we just continue as is - missing opportunities whilst we argue about something. Meanwhile in the iD project the developers are splitting the project into a core component and an OpenStreetMap plugin. If we’re not careful this will result in new features being developed entirely behind closed doors (e.g. a dedicated version of iD for Company Y) which we have no say in but also don’t get to benefit from if they are good features.
Conclusion: If we can find a way to make decisions as a community we can then help drive in this direction rather than just being a passenger not knowing exactly where we will go or how long it will take.
Comment from Mateusz Konieczny on 10 November 2019 at 20:51
I think that title is poorly chosen, situation is NOT so bad. And in this topic clickbait is not needed to generate discussion and views. And it makes situation worse.
Though:
(1) iD developers are not obligated to follow OSM Wiki, tagging mailing list, OSM community etc and so on. (2) iD developers on some occasions decided to use that, in ways and cases that went beyond what JOSM authors do (3) OSM community is not obligated to deploy unmodified iD editor as the default editor
In case of switching from iD to iD-with-community-changes I would strongly suggest to
(0) at start decide how it is going to be managed - how it is going to differ from iD? What is considered as a problem that people want to avoid? (1) at start give it as one of possible choices in dropdown to look for bugs and other unexpected issues
There are many other things here, but for specific
linking to https://github.com/frodrigo/iD/tree/compliance
It is completely missing - info in README how this fork differs from iD - info in README is it going to incorporate future iD changes - issue tracker (Github one is disabled)
Without fixing this it is too early to even think about deploying it as the main editor or even one of editors on the OSM website.
Also, I would advise pushing it as a separate repo, sharing commit history. Github status “ forked from openstreetmap/iD” has some consequences that may be problematic in future.
Comment from Mateusz Konieczny on 10 November 2019 at 20:54
Repeat of previous one, hopefully without eaten newlines.
I think that title is poorly chosen, situation is NOT so bad. And in this topic clickbait is not needed to generate discussion and views. And it makes situation worse.
Though:
In case of switching from iD to iD-with-community-changes I would strongly suggest to
There are many other things here, but for specific
linking to https://github.com/frodrigo/iD/tree/compliance
It is completely missing * info in README how this fork differs from iD * info in README is it going to incorporate future iD changes * issue tracker (Github one is disabled)
Without fixing this it is too early to even think about deploying it as the main editor or even one of editors on the OSM website.
Also, I would advise pushing it as a separate repo, sharing commit history. Github status “ forked from openstreetmap/iD” has some consequences that may be problematic in future.
Comment from Nakaner on 10 November 2019 at 21:26
I agree with Frederik. The way how the maintainers deal with people disagreeing with them cannot be accepted as it is.
Maintainers of a project of that importance – especially if they are paid – should be able to get along with people not liking their decisions. If they face constant disagreement, they should ask themselves who’s really wrong. Is it the community not understanding their great vision? Or do they not realise being on a motorway but driving into the wrong direction?
Simply locking these tickets as being “too heated” (https://wiki.openstreetmap.org/wiki/ID/Controversial_Decisions links to almost all of them) is not a solution of the dispute. Regarding attempts of mediation with dislike isn’t either. Excluding a large number of people from being community members and enclosing yourself in a more or less gated community does – together with the reactions above – lead myself to the impression that they have a serious problem with dealing criticism.
All this was topped by an action I hope to be regretted retroactively. On Friday, comments and creation of new issues was disabled for everyone except collaborators. (It was re-enabled a few hours later) This cannot be a solution! If one try to lock out criticism, your following an unsuccessful pattern (look at a couple of countries being the media these days).
There are a couple of options to get out of this stuck situation: * Frederik suggests a solutions which is common with Linux distributions patching upstream code. This has the great benefit for upstream maintainers that people disagreeing with them can still convince the distributor to apply a patch to make them happy. On the other hand it is a huge sign of distrust, basically like voting a prime minister out of office ahead of time. * Another solution would be the maintainers to realise the stuck situation themselves and pausing their engagement with iD development until the end of the year except important bugs. An provisional maintainer should watch bug reports and report real, severe bugs to the maintainers but holding them away from everything else.. It would grant them a cool-down period to relax, something at least one of the maintainers seems to seek for a couple of month (it was repeated on Slack these days with a different wording).
I hope that the maintainers realise that we are running more and more into a dead-end road with an undesirable end.
maxwerickson wrote:
Most of these requests are valid. I review issues myself and comment those which are questionable or worse (but I don’t comment all the others in order to keep down the noise level). The complaints about the iD developers treatment of change request refers to those they decline.
phideaux wrote:
I agree that they fix bugs very quickly. Their presence on the OSM-US Slack is not a surprise (as mine on #osm-de). People often have a preference for domestic communication channels. However, someone acting on a world-wide level should respect international channels, especially if the channel is dedicated to a topic one has a large influence of or works a lot with in an influential way. This is the Tagging mailing list. People on that mailing list are very dedicated to tag design and tag usage. It is the accepted communication channel for Tagging. If the majority of people disagrees with ones decisions, they aren’t abusive or unwelcoming. They are just telling you that they don’t agree with you. One should keep in mind that member of the OSM community come from very different cultures and that applies to their way calling things good or bad.
maxerickson wrote:
I might agree with that partially but it should not happen in an unilateral way. It is not the task of the iD maintainers to deprecate tagging. Instead, they should try to implement community consensus as best as they can.
Most disputes with iD are related to tagging. If the maintainers handed over these issues to a committee, they would get rid of most decisions and people would point their fingers less often onto them.
maxerickson wrote:
It is not user friendly but European law requires us to do so. Most user consent is already implemented in iD, it’s called “change background imagery”.
Comment from Nakaner on 10 November 2019 at 21:40
I forgot to wrote that I intentionally used “maintainers” not “developers” because there are more people than the maintainers contributing to the source code. However, none of the current non-maintainers committing to the source have be involved in the disputes. My criticism does not refer to them.
Comment from mikelmaron on 11 November 2019 at 02:07
This is a new low in the OSMF poisoning our development environment.
I don’t see how a post like this one does anything to build community and good tools. The problems you point to of poisonous communication channels and antagonistic environment for developers go well beyond iD, and are present all over OSM. There are many people on “all sides” upset with how people behave in OSM. The only reason you point your finger at iD is I think because it nurses your imagination of an evil corporate plot. It’s totally unhelpful to our community.
These accusations of actions by iD developers of “a mandate for more” are particularly distorted.
The developers of iD have very clearly stated they do not want to be arbiters of tagging decisions. The confusion in tagging are fundamental to OpenStreetMap, beyond the scope of iD.
Huh, what does these mean?
Who’s striking a deal?
You’re talking about the brand logos? Putting aside whether there was discussion or not, I tend to agree that this issue could be easily solved by something as simple as caching logos on osm.org assets, or making the behavior optional.
Now I certainly don’t agree with all actions taken by the iD developers in regard to how communication is handled. However, I am sympathetic to the pressure they are under. We as the OSMF should not put the responsibility to deal with this kind of all sided criticism. That a member of the OSMF Board should also join in and attack people who are dedicated their work to our main editor is shameful.
We need to have a higher standard of how we help OSM develop. Yes it’s harder work than pointing fingers, but it’s work we need to do. The developers of iD are not enemies of OSM, and I am sure are ready to figure out how to better manage things, given a chance to work together.
Comment from Mateusz Konieczny on 11 November 2019 at 09:42
It is not changing this part of your comment, but we are lucky to have two - see https://github.com/openstreetmap/openstreetmap-website/graphs/contributors
Comment from Mateusz Konieczny on 11 November 2019 at 09:46
@title
Yesterday I complained a bit about a poor title. But I think that it is actually a major issue.
Big part of this problem is that some groups are irritated/frustrated. Such strong pejorative terms are really damaging and are not making situation better. This is really not the best moment to go for a hyperbole.
– signed, someone who dislikes that iD attempts to redefine highway=track
Comment from SimonPoole on 11 November 2019 at 10:58
@Adamant1 for accuracies sake, neither of the current developers had anything to do with the creation of iD as a concept nor with the couple of initial releases of the product. We don’t even know if the current vision for iD even continues to include OSM.
Comment from SimonPoole on 11 November 2019 at 12:24
@adamant1 you yourself should perhaps be a bit more careful, I haven’t seen anything in woodpecks post that would even remotely add up to slander.
Comment from mikelmaron on 11 November 2019 at 13:24
@SimonPoole I think we should all be more careful. This entire thread about an “abusive relationship” is way overheated and distorted. I’d love if we can step back from the fighting, and start thinking about how to help OSM software development work better.
Comment from Richard on 11 November 2019 at 14:53
Frederik, I think you (and Mikel) could usefully reflect on your role in this - or lack thereof - as OSMF directors. Saying nothing for n years and then firing off a broadside just as you leave office is pretty weak sauce.
Most of this ultimately comes down to the differences (which can be overstated) between “craftmapper” OSM and “corporate” OSM, aka between European OSM and American OSM. Unsurprisingly, if you have an editor which is developed by American programmers employed by large OSM-using corporations, it is going to lean more towards the American/corporate side of things. The fact that the divergences are mostly as minor as “the developers prefer the 1 out of the 500 OSM communications channels I don’t use”, or “the developers have an opinion on tagging, a subject on which no two people ever agree, with which I disagree”, or “the developers load images from servers I don’t like”, suggests they’re doing a good job in the round IMO.
But that’s only my personal view. The point is that OSMF could have done something about it. If OSMF feels that iD is not fully representing the OSM contributor base, then OSMF, which has £££ in the bank, could fund a European maintainer - or, perhaps better, a “community maintainer” - to join Bryan and Quincy. It hasn’t done. As a director, that is your choice by omission.
Maintaining the default editor is not easy. That is something that has been public knowledge since 2013, arguably long before. It is probably unrealistic to expect anyone to work on it without being paid, particularly given the grand tradition of “BAN POTLATCH” postings like this. You are smarter than the Potlatch Banners of yesteryear, not just more articulate, and I am a little disappointed by this posting.
Comment from tuxayo on 11 November 2019 at 17:15
Thank a lot woodpeck for providing your summary on these issues. I wasn’t aware of these and will carefully read everything linked.
Comment from ain92 on 12 November 2019 at 11:59
I would like to add an example of abusive behaviour by an iD developer. Many schools in Europe located in city centers don’t have any school ground (e. g.). At the current moment using an amenity=school iD preset on the school buiding removes building=yes making the school disappear from most renders.
This issue was adressed in two tickets with wide community support, both were closed by the same maintainer without community arguments and uneasiness being adressed: “Please stop bothering us about this issue”, “Please stop trolling our project”.
This is unexceptable, a developer should be a servant of the community, not an autocratic dictator. I believe that we should issue an ultimatum to the maintaners, be they paid or unpaid: if their attitude doesn’t change, we will proceed as proposed in this post. Pic related (yes, this is Jimmi Wales).
Comment from ain92 on 12 November 2019 at 12:01
*unacceptable (sorry, was writing in haste)
Comment from Richard on 12 November 2019 at 12:03
@ain92, it would perhaps behove you to have a bit more experience in OpenStreetMap than 100 changesets before you start telling long-standing and dedicated contributors what is “unacceptable” and demand that “ultimatums” are issued.
Comment from literan on 12 November 2019 at 12:18
@Richard, I subscribe to all ain92’ words. Hope, I have enough OSM experience to do this.
Comment from Richard on 12 November 2019 at 12:24
@literan It’s not acceptable for anyone to say “a developer should be a servant of the community”. A developer is a part of the community. It takes mutual respect. There are things in iD, and JOSM, and osm-carto, and osm-website, and pretty much every part of OSM that are not exactly how I’d do them. That does not give me or you or anyone the right to start issuing ultimatums.
Comment from Mateusz Konieczny on 12 November 2019 at 16:33
“a developer should be a servant of the community” is an absurd demand, for multiple reasons. Though obviously attempts to become “autocratic dictator” also are absurd and not acceptable.
“A developer is a part of the community.”
+1
Comment from ain92 on 12 November 2019 at 17:15
@Adamant1 “he was tired of it” As the post we are commenting demonstrates IMO, some maintainers are quite systematical in the behaviour you are condoning. I strongly disagree that throwing away reasonable community objections in this manner is OK.
“not something that is on his end to fix anyway… amenity tags work that they be mapped on areas and not buildings” Check the second ticket, it adressed that issue precisely. The preset doesn’t take this into account, while it should, and a user did suggest changing the UI to fix it, only to be accused in trolling.
@Richard “It takes mutual respect” “Servant of the community” was a figure of speech, I apologize if it sounded disrespectful and agree with your formulation “a part of community”. My point doesn’t change much from that though.
Comment from SviMik on 12 November 2019 at 17:47
@Adamant1 I disagree regarding “not something that is on his end to fix”. If users keep misunderstanding the presets that an editing program provides, then it is preset problem (the way how the preset is named and described), not the user’s problem.
Also, iD could throw a warning if user tries to change the type of an object to an incompatible one. It’s a good practice to warn user if something he does is suspicious and possibly not what the user wants. The provided example looks like a simple case to program, simply to show a warning message when user tries to apply an amenity preset to a building.
Blocking the comments without trying to understand what exactly people try to suggest is inadequate, especially if the suggestion is not to change the way the preset work, but quite the opposite - to make it more clear to users how it works.
Comment from dieterdreist on 13 November 2019 at 14:26
WRT to tagging consolidation and „picking the winner“, in more than one occasion this is a completely misleading reading of what iD developers did, and they also explicitly confirmed it more than once: they have been inventing and introducing new tags, dismissing the used schemes and introduced new ones. Some of these have happened by accident (and a better community integration would have likely prevented it), in other cases it was completely conscious and on purpose (“the existing scheme was too complicated so I was making a new one”).
Comment from woodpeck on 13 November 2019 at 14:30
I’ll offer a couple quick comments on the feedback I have received.
Most importantly, I underestimated the reach of this medium; I had assumed it was essentially consumed by OSM insiders who would have been part of past discussions and hence know the background. Apparently not so, and I apologize to those readers who had to cobble together the background by asking others. I shall give more context in the future.
Some people said that I am lamenting a situation which I, as an OSMF board member, could instead have fixed or helped fix. That’s a fair point; had I concentrated on this one issue I might have been able to move something. I haven’t done that. But does that failure disqualify me from pointing out issues for all eternity? Even the fact that people think the board should get involved is already a sign that something isn’t working right.
Some people tried to tone-police me and disqualify the point being made based on allegedly “toxic” expression. If you are one of these people and have in the past chided the iD developers when they gave condescending replies to polite and factual criticisms, good for you; if you, however, singled me out for “toxicity” while happily turning a blind eye to “toxic” remarks by the iD developers in the past then you are being very selective.
Some said I should have given more examples of what the problem was; I trust appropriate links to issue trackers and mailing list posts have meanwhile been passed around. Again, I mistakenly assumed that everyone had been following the issue.
Some people hoped to advance the discussion by referring to my age; I don’t see what this has to do with anything but I hope you had a good chuckle with your youthful pals on whatever social media platform is en vogue. Guess your next witty joke is going to be about someone’s skin colour.
Some people see an “USA vs. Europe” schism here but I didn’t when I wrote my piece; there are US American maintainers of Open Source projects who manage to behave respectfully towards those who use their software and there are Europeans who give everyone the finger. So, meh.
This isn’t the first time we are having this discussion, and in an earlier instance someone has eloquently said more or less the following: The iD developers excel at coding an user-friendly editor, and they suck at interacting with the community. Communicating their plans, getting buy-in, and dealing with criticism shouldn’t be their job; they should concentrate on what they can do well. De-coupling the OSM web site from the iD release cycle will help with that; ensure that whatever the iD developers do only goes live after it has been carefully looked at. It is not a solution but the first step of one.
And finally, someone complained that I brought “abusive relationships” into this, thereby belittling the suffering of those caught in such situations. My reason for this was that people in abusive relationships often cite reasons for not ending them that go like: “Deep down my partner loves me, and when they lash out this is just because I said something wrong”, or, “I know it is sometimes difficult but I cannot imagine how I could live without my partner”. I found that this mirrors what people in OSM say about iD. I didn’t mean to equate actual physical harm with a couple snotty comments on GitHub, and I’m sorry for that.
Comment from mikelmaron on 13 November 2019 at 14:52
Thanks for acknowledging that “abusive relationships” and domestic violence are not akin to what it’s like to develop software in OSM. It’s a horrible analogy. Btw, I complained about this, but not publicly, but directly in a Board internal conversation on this topic.
I do think Board members have more responsibility in discussions like this. We have more awareness and influence in our role. It’s harder work than writing a rant. Yes, you may not individually have had time to contribute to this issue, but writing something like this publicly undermines the efforts of Board members who are.
The criticisms of this post are a lot more fair to you than your reaction lets on. There is plenty of acknowledgement that there are problems in how iD developers communicate – I readily say so. However they do not only “suck at interacting with the community”, since there are plenty of examples of quality interactions as well. I can say that this very diary post is an example of “sucking at interacting with the community”, but I am would not paint everything Frederik does in that vein.
What remains after unpacking all this baggage is an idea to unilaterally hand over deployment choices to a hand picked successor. That’s ill conceived, and focuses only one part of OSM software development that has issues. This is also tightly wound up in the confusion of how tags are developed. There are certainly better ways to manage this, and we should work hard on that, but it’s going to start with a broad discussion of how we can all work together better.
Comment from SviMik on 13 November 2019 at 15:10
@Adamant1 Well, there are several reasons why I opened a new ticket: 1. According to his answer, he did not understand what I was talking about before blocking comments in that issue. Either he didn’t actually read my comment or I phrased it poorly—we’ll never know. I understood it like ‘okay, it was probably a bad idea to suggest a different thing in the same thread, because people can’t see past the issue title, I need to make a separate issue on that’. 2. The new issue was targeting a different thing. Literally #5883 was ‘please change the preset behavior’ and #6899 was ‘okay, do not change the preset behavior, but make it clear to users that it works in that way’. I cannot wrap my head around why people don’t see the difference—is my English that bad or they just skim through the text without actually reading it?
Comment from amapanda ᚛ᚐᚋᚐᚅᚇᚐ᚜ 🏳️🌈 on 15 November 2019 at 06:39
Er, yikes no. A bad use of “ok boomer” isn’t comparable to racial based insults.
Comment from tuxayo on 15 November 2019 at 06:59
Booth are ad hominem attacks right? https://en.wikipedia.org/wiki/Ad_hominem
Comment from Mateusz Konieczny on 15 November 2019 at 08:33
Note that widely varies across people what kind of ad hominem attacks are hurtful.
Age based insults can be very hurtful. 15 years ago it would be for me one of the most offensive ones. It is likely to be true again in the future once I am hit by various old-age related issues.
I would not dismiss it so easily that something for you personally is not problematic would hurt others. It varies wildly based on personal, historic, social and other contexts.
Comment from Diomas on 19 November 2019 at 23:48
https://github.com/openstreetmap/iD/issues/5398 just… wow basically “we don’t give a %$#* about your problem in tagging this case, no matter how people used to do this before - we don’t care, just try to solve it by creating an extra geometry”