Talk:Automated Edits code of conduct

From OpenStreetMap Wiki
Jump to: navigation, search

Discuss Automated Edits/Code of Conduct here:


Overwrite race

The guidance reads: "do not simply use yesterday's planet file as a basis for uploading changed objects as this would break changes made in the mean time". Is this still true with the 0.6 API and optimistic locking? It seems to me that the OSM server woudl reject the edit and answer with "conflict". User:Jrouquie 18:52, 4 August 2009

Optimistic locking certainly helps. Maybe this text should be altered in some way to reflect that. However the problem doesn't go away entirely. For example if you have a database of postboxes, and then you do buffer comparison with existing OSM data, to figure out which ones need adding... better make sure you're working from reasonably up-to-date data from OSM because optimistic locking won't prevent you adding a duplicate. -- Harry Wood (talk) 17:49, 26 March 2015 (UTC)

Proposed merge with other pages

I've removed the merge proposal links, as there's been no updates or discussion on the merge in two years. See also the Talk:Mechanical Edit Policy page. zool 10:32 27 Dec 2014

The Mechanical Edit Policy merge to here was since carried out (March 2015). See Talk:Automated edits policy#Merged to 'Automated Edits code of conduct' -- Harry Wood (talk) 15:24, 19 May 2015 (UTC)

Merged content from 'Talk:Automated edits policy'

This section is a cut and paste merge of the contents of Talk:Automated edits policy. The page itself was merged into this article some time ago, and it seems appropriate to bring the discussion with it. PeterIto (talk) 06:54, 20 May 2015 (UTC)

More work needed?

This policy seems to be unfinished. The example link is to a non-existent article and there is no Mechanical Edits category (to which one is required to add one's pages). Should this article not be completed? When it is complete can we redirect the Automated Edits code of conduct article to this one? PeterIto 09:57, 21 January 2012 (UTC)

Alternatively, should we update the Automated code of conduct with the text in this article? PeterIto 15:53, 21 January 2012 (UTC)

Mechanical or Automatic?

Do we need to introduce a distinction between Automated Edits and Mechanical Edits (note that there is no article yet for 'Mechanical Edits' yet)? Personally it seems better to stick with one term. Please join the discussion this point on Talk:Automated Edits in the 'Terminology - Automated edits, bots or Mechanical edits? ' section. PeterIto 15:52, 21 January 2012 (UTC)

Proposed move Mechanical Edit Policy -> Automated edits policy

I propose moving this page to "Automated edits policy". Any thoughts, for or against? PeterIto 11:56, 31 May 2012 (BST)

As discussed Talk:Automated Edits#Terminology - Automated edits, bots or Mechanical edits? ...I agree with the move. I think it makes sense just to align terminology. Which is the more "correct" terminology is much-of-a-muchness. Is User:Frederik Ramm ok with a rename? (he wrote this policy as part of his Data Working Group work) -- Harry Wood 18:52, 31 May 2012 (BST)
There is a difference between Mechanical and Automated edits. All automated edits are also mechanical but not all mechanical edits are automated. We chose the wider-scoped name "mechanical edits" to make it absolutely clear that loading 100 objects through the XAPI and "manually" making a bulk change to them in JOSM is also covered by the policy. I'm happy to defer to native speakers but I fear that "automated edit policy" would be judged by many as not applying to their particular edit. - What about the term "bulk edit"? --Frederik Ramm 19:48, 31 May 2012 (BST)
Well you're the main creator and user of the page (I presume you link people to this a lot with your DWG activities) so I don't think we should move it if you're not happy to do so.
There's a certain elegance (and less terminology introduced) if we just have a trio of pages Automated Edits, Automated Edits code of conduct, and "Automated Edits policy". Obviously that's only a good idea if "Automated Edits" always means the right thing
I think loading 100 objects through the XAPI and "manually" making a bulk change, could still perfectly well be described as an "automated edit" (equally well as describing it as a "mechanical edit" really). In fact the page Automated Edits does already say "the term is also applied to" the XAPI thing. We could make that clearer.
...or just leave as is.
-- Harry Wood 09:40, 1 June 2012 (BST)

The pages are also inconsistent at the moment regarding where to "document" stuff on the wiki. Here on Mechanical Edit Policy#Document it says create a subpage of Mechanical Edits, and we can see a few people are doing that. But then over on Automated Edits code of conduct#Document what you have done, or are doing it directs people to add to Automated Edits/Log. -- Harry Wood (talk) 10:10, 5 June 2013 (UTC)

I'm removing the proposal link from the top of the page; as it has been a year and a half since the inconclusive discussion, it looks like this proposal has failed. -- zool 10:00 27 Dec 2014 (UTC)

Following this, see discussion below. (User:Peterito has since done the rename and then further rationalisation)

Local mailing lists

The policy suggests using "national-language mailing lists" for announcing the edit. I think that a the regional mailing lists that exist e.g. in Germany are much better suited if only that area is affected by the edit. For example, if I was planning a mechanical edit of bus stops in Berlin, then the Berlin mailing list would be a better choice than talk-de. So I suggest adding "The regional mailing list for the region affected by the change" to the list in the "Discuss" section. Tordanik 02:57, 20 May 2012 (BST)

Makes sense to me. PeterIto 11:53, 31 May 2012 (BST)

Real name

  • Who is making the change (real name and how to contact, ideally e-mail address)

I don't see why publishing your real name should be required - that's uncommon in the OSM community outside the mailing lists. A possibility to contact the responsible mapper is necessary, of course, but otherwise an OSM username is sufficient. --Tordanik 02:57, 20 May 2012 (BST)

Agreed. OSM name should be sufficient, as long and the editor commits to response to messages through it. PeterIto 11:48, 31 May 2012 (BST)

Uncontroversial edits

A more general objection to this policy is that it imposes an excessive amount of bueraucracy even for uncontroversial edits. Creating a wiki page before fixing, say, straightforward typos like "traktype=grade4" is totally unnecessary in my opinion - that much can be adequately documented in the changeset comment. I think it is fine to use your judgement whether or not an edit is potentially controversial, and skip the paperwork when it is not. --Tordanik 02:57, 20 May 2012 (BST)

Makes sense to me. It gets more political when one decides that 'yes' should be 'true' of course. Typo fixes, like converting 'tru' to 'true' or 'ys' to 'yes' for a boolean tag sounds good. Wikipedia uses them all the time. PeterIto 11:51, 31 May 2012 (BST)
But what's an "Uncontroversial edit". Talking to people after they've done a bad thing with a wide-scale bot edit, they almost always believed they were making an uncontroversial change at the time. Creating a wiki page is easy, but if it's too much hassle for somebody... It begs the question, are they going to the hassle of thinking about what they're doing at all??
In fact I think we should start back-dating the rule about a wiki page per import/edit to all previous automated edits. With a page naming convention we could seek to catalogue a lot of them. We can create stubs with some information even if we have zero input from the user concerned. Then in these cases we start to build a list (wiki category) of users who didn't bother documenting their activity (name and shame)
I can accept that there are shades-of-grey cases where it's only sort of very semi-automated (searching over a small area in JOSM) These cases go under the radar anyway, and if for some reason they're not under the radar, then the policy applies. Wiki page please.
- Harry Wood 18:44, 31 May 2012 (BST)
If you think that "uncontroversial edits" is too broad, let's look specifically at a common class of truly uncontroversial edits: "typo fixes". You will usually not mistake your mass edits for typo fixes if they aren't. These are practically never being discussed in advance, happen frequently and often cover a wide area. Nevertheless, they don't cause trouble, and they are useful, not the least because due to the way some editors work (e.g. using nearby tags, including possible typos, for auto-completion). --Tordanik 19:14, 6 June 2012 (BST)
I agree with this 100%. Otherwise it is sad to see typo-ed data sitting in OSM without any way to fix them (this policy is too complicated and even unacceptable to some users) and knowing users even took the effort to put data into OSM but it will be ignored by software due to accidental mistakes. - aceman444 23 Aug 2013
Just one problematic issue which came to my mind: Hmm, and what if you did not think of the "traktype=grade4" which describes the type of "trak"? A trak is a special type of meadow in South Korea for child play and sports... (no, not really, just an example). Others may spot such problems if you discuss it before. --Aseerel4c26 (talk) 18:53, 11 February 2014 (UTC)
In the very unlikely case of undocumented and unmentioned tags which look like commonplace typos, we can still correct the mistaken edit after the fact. It's not as if discussions are a panacea: Even with a discussion, mistakes will slip though, and if people would really discuss every trivial correction, then soon nobody would even read such threads anymore. Ultimately, the goal of any rules should not be zero risk - there has never been a zero-risk edit in OSM -, but the best ratio of risk, effort, and reward. And after proper research, typo corrections in general have a very low risk of going wrong. Most of them just silently make the database a little bit better. --Tordanik 05:59, 12 February 2014 (UTC)

Moved to 'Automated edits policy'

I have moved this page from 'Mechanical Edit Policy' to 'Automated edits policy' for the reasons discussed above. This is part of a wide ranging set of edits to clarify the whole subject of bots, automated edits and mechanical edits etc etc. Feel free to discuss this as I will be working actively over the next month or so. PeterIto (talk) 14:59, 10 March 2015 (UTC)

Merged to 'Automated Edits code of conduct'

Am doing a bunch of rationalisation about the area of bots, mechanical edits, automated edits and the associated categories. It does now seem logical to merge the content from this article into Automated Edits code of conduct which covers an almost identical subject with many of the same headings. Happy to discuss what I am doing here. PeterIto (talk) 17:15, 10 March 2015 (UTC)

I have now completed a merge of this article into Automated Edits code of conduct and converted this article into a redirect. Will now complete the integration of the combined content. PeterIto (talk) 10:59, 11 March 2015 (UTC)

Nicely done. Seems like a good rationalisation to me. -- Harry Wood (talk) 18:04, 26 March 2015 (UTC)

Veto

The clause "Provide a means for mappers to "opt out" of your changes, i.e. if someone contacts you and asks you to stop making automated edits to things that they have edited, you must comply with that wish, and you must modify your software or procedure to leave those objects untouched in the future" is impractical and over-restrictive. Where - if ever - was consensus for it reached, and does that still hold? Users should not have a veto over others' edits. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 18:52, 6 June 2015 (UTC)

Good point. To be clear, although I have done a lot of editing on the wiki over the past months, I have tried not to change the meaning. However, I do think it will be useful to discuss and challenge this statement. The guidance from WP, Ownership of articles may be worth reading. PeterIto (talk) 15:57, 7 June 2015 (UTC)
Users don't have a veto about other users' manual edits, but about other users' mechanical edits because a manual edit represents a bigger commitment than an automated edit. The latter is considered generally less valuable. --Frederik Ramm (talk) 16:55, 9 May 2016 (UTC)

Automated edits deleting legitimate content should not be condoned

The following section does not seem to fit with the rest of the page :

"In cases where edits that are in violation of this policy are so closely mixed with "normal" edits that it is difficult to tell them apart, it is possible that reverting the problematic edits will also cause some collateral damage among the "normal" edits."

This legitimize reversal (automated edits) without verifications being done, which is in direct infringement of the AE CoC.

Please note that this section was added after a DWG member reverted 80 changeset as it was believed that they were mecanical, but 14 of them were not (changeset 27888534). --Gileri (talk) 20:20, 13 September 2016 (UTC)

First you start a changeset discussion on http://www.openstreetmap.org/changeset/27888534, then when you're not happy with the outcome you discuss it on the mailing list https://lists.openstreetmap.org/pipermail/talk/2016-July/076291.html and when you don't get the desired support there you try to start a discussion here. I added the section above precisely to warn people to *not* closely intertwine legitimate edits with policy-ignoring mechanical edits after you complained that some legitimate edits were lost in this revert. This is unavoidable and it will happen in the future if people don't adhere to the rules. I told you time and time again that, if the editor in question had made the smallest effort to properly document his mechanical edits as the policy requests, the revert could have been done better. You seem to think that if the DWG reverts a mechanical edit that the revert is in itself a mechanical edit that has to follow the policy. If this settles the matter, I am happy to add the sentence "A revert of a mechanical edit by the OSMF DWG is not a mechanical edit and not subject to this policy". Otherwise I'd be happy if you could take your squabbling elsewhere because I am getting tired of it. There would not have been *any* problem if the user had not added the 64 changesets that you admit were mechanical edits, but you haven't *once* seen a fault in the user's action - all you can talk about are the 14 changesets that have been lost in attrition. This is not a sincere argument, this is just petty tit-for-tat. --Woodpeck (talk) 21:48, 4 September 2016 (UTC)
Okay I will not answer to the "personnal spikes". You seem to take discutions about reverts and AE very seriously. It is good to have a passionate debate, but no need to attack people for constructive criticism. I agree to the points in the AE CoC asking to make AE distinguishable from other more "handcrafted" changesets. However, there need to be verifications being made before reverting changesets (even more when multiple changesets are reversed). You can't ask contributors to jump so many hoops and invest so much time in order to be allowed a AE, but allow blind reversal of a lot of data at the same time. Before making the change you suggest to the CoC, don't you think it would be best to document the edit you are suggesting and secure a consensus before modifying a text which is so important for OSM ? --Gileri (talk) 19:15, 5 September 2016 (UTC)
I read again the thread on the mailing list, and tried to compile some kind of "vote" : in the 10 persons who have expressed a direct opinion on the current state of the AE CoC, 4 were in agreement with some or all of my suggestions, and 6 were fine with the current state. I found this discussion useful as it has shown a lot of different opinions and suggestions on AE-related things. So I don't think of this thread as negatively as you seem to do. --Gileri (talk) 20:20, 13 September 2016 (UTC)
I saw the addition of the sentence about edits "so closely mixed with "normal" edits that it is difficult to tell them apart". It seemed sensible addition to me. If you jumble together good edits with bad in a way which is difficult to unpick, and your bad edits (in this case "automated edits", but really any kind of bad edits) need to be reverted, then I'm afraid you are at risk of losing your good edits. Not that anyone will take any pleasure in doing it. We like good edits, and we want to keep them. But if you've mixed it all together, then that's the action we're left with. This is really just reminder about doing the sensible thing. It ties in well with advice already present in the Automated Edits code of conduct#Execute with caution section. -- Harry Wood (talk) 22:20, 6 September 2016 (UTC)
I think we all understand what is meant by this section. It is understandable to explain that in some cases it can be really hard to distinguish what the AE CoC consider "manual edits" and "automated edits". But this sentence is too permissive imo, as for example it has been used to legitimate the revert of this changeset for example. The main criteria to distinguish "automated edits" and "manual edits" is often the number of changes made, I think it's easy enough to just open the changeset and see the number of edits before reverting them. I (and other contributors I believe) can volunteer to check such changesets if DWG's members doesn't have the time to do so. --Gileri (talk) 20:24, 7 September 2016 (UTC)
The wiki page may have some explanation related to what DWG does, and Frederik's here representing DWG in this discussion so you might ask him to whether this is accurately reflecting the approach they take. You might have a discussion (here or on a different channel) about whether DWG is taking the right approach. But... "too permissive" ... we can't expect to adjust the contents of this wiki page to dictate to DWG what they can and can't do. That's not how this works. If anything this page is written by DWG to help them in their work.
So you're in the wrong place really. Discussing a bit more directly with them about this particular case seems like correct way forwards for you here, but it sounds like you've already tried and failed at this. Take a deep breath and try not to be too combative about it (you'll need to be the exact opposite in fact, in order to turn this discussion around) I know it fees like combat when someone reverts some edits, but seriously, take a deep breath. Understand the big picture situation regarding automated edits and building a map and a mapping community.
Good that you're volunteering to take the time to check such changesets. Without looking into the details, I think I'm right in saying that DWG will welcome folks doing this sort of thing, preferably on a local level, and preferably negating the need for their involvement at all.
The ideal thing would be when User:Test30 comes along and does automated editing in your area, you, as a local person, spot what they are doing and proactively point them at these guidelines, make sure they split out their edits (Plus maybe ask them to add a user description and describe what they're up to with automated tools, and ask them why their username is "test" when they're not editing the test OSM database etc etc. It doesn't need to be solely DWG's responsibility to have these discussions). I take it that didn't happen. DWG did a big revert. Now I imagine your input after-the-event can still be very useful. If you feel some good edits were lost, and you're volunteering to unpick that. The good edits could be re-applied. Work with DWG on it. Do it properly. It seems like a good way to help.
-- Harry Wood (talk) 12:05, 8 September 2016 (UTC)
That is one of the problem with this page : any member of the DWG can add any directive, and it becomes a "law" that no one can discuss : both of you (Harry and Frederik) totally dismiss the original argument, and tell me to "take my squabbling elsewhere".
I don't think that discussing privately with the DWG is the right approach, because as you can see, any argument become immediately met with harsh comments and dismissed, even in the open.
You imply that I don't understand OSM and what's it about, whereas you understand perfectly. I will not pretend I've been as much involved as you both in OSM, but I think I understand enough to be allowed constructive criticism on such matters.
As I said previously, if I spotted any edits like these linked in OP, I would have opened the changesets and read what they were about before taking actions like reverting. I feel like that's what is expected of contributors but the DWG seems above that.
Based on your whole answer, I can assume that you did not read about the changesets I linked, and that's too bad because it shows exactly what my OP was about. Instead you suggest that I pick up the broken pieces months after because the reverter won't admit that their revert was too broad and reinstantiate the wrongfully removed data. I think that's a tad condescending, but don't worry, I'm not combative about legitimate arguments, even if you seem to assume so.
A question to wrap it up : if the reverter wasn't from DWG, do you think this revert would have been kept ? --Gileri (talk) 18:47, 8 September 2016 (UTC)
As people who all sincerely think they’re doing the right thing for OSM and the community clearly aren’t seeing eye to eye, maybe we could organise a conversation about this at State of the Map.--Andrew (talk) 11:35, 7 September 2016 (UTC)
That's a good idea, some people may prefer discussing IRL over issues like this. --Gileri (talk) 20:20, 13 September 2016 (UTC)
@Woodpeck «If this settles the matter, I am happy to add the sentence "A revert of a mechanical edit by the OSMF DWG is not a mechanical edit and not subject to this policy".»
How legitimate would that be? For the first time, the DWG would have a special status when dealing with AE despite it's mission being dealing with copyright violations and serious dispute/vandalism. Theses missions require the power to block accounts but not AE issues. (most don't end up in beeing serious desputes/vandalism)
About reverts being AEs: I agree that a revert of a problematic AE is not an AE. Of course one shouldn't revert a changeset without checking if it's a problematic AE but considering a revert an AE will add more complexity and won't help resolving disputes. --Tuxayo (talk) 11:12, 25 September 2016 (UTC)
I don't think this section can justify changeset 27888534 as they are independent changesets with a limited number of objects and a limited area. Of course I do feel that it's here to justify changesets 27888534 as it was added after the discussion on this changeset. But I don't think it actually justifies it as changeset 27888534 is out of this scope IMO. But anyway, changeset 27888534 has it's own discussion.
To get back to this section I don't think adding it was a good idea. It's obvious that a changeset where there is a mix of automated and manual edits will lead to collateral damage if revert is needed. Adding a paragraph each time there is an AE revert controversy won't avoid them in the future. --Tuxayo (talk) 11:12, 25 September 2016 (UTC)


Rules for Robot/A.I. Mappers

background: Robot Mappers , machine-learning and artificial intelligence (“robot”) techniques ; http://mike.teczno.com/notes/openstreetmap-at-a-crossroads.html

Maybe, in the future we need some ethical suggestions, like

  • "Robot mappers must be designed to assist humanity" meaning human autonomy needs to be respected.
  • "Robot mappers must be transparent" meaning that humans should know and be able to understand how they work.
  • "Robot mappers must maximize efficiencies without destroying the dignity of people".
  • "Robot mappers must be designed for intelligent privacy" meaning that it earns trust through guarding their information.
  • "Robot mappers must have algorithmic accountability so that humans can undo unintended harm".
  • "Robot mappers must guard against bias" so that they must not discriminate people.

based on Satya Nadella's A.I. laws —Preceding unsigned comment added by ImreSamu (talkcontribs)